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Abstract 


This document defines the schema for representing Java(tm) objects in 
an LDAP directory [LDAPv3]. It defines schema elements to represent 
a Java serialized object [Serial], a Java marshalled object [RMI], a 
Java remote object [RMI], and a JNDI reference [JNDI]. 


1. Introduction 


This document assumes that the reader has a general knowledge of the 
Java programming language [Java]. For brevity we use the term "Java 
object" in place of "object in the Java programming language" 
throughout this text. 


Traditionally, LDAP directories have been used to store data. Users 
and programmers think of the directory as a hierarchy of directory 
entries, each containing a set of attributes. You look up an entry 
from the directory and extract the attribute(s) of interest. For 
example, you can look up a person’s telephone number from the 
directory. Alternatively, you can search the directory for entries 
with a particular set of attributes. For example, you can search for 
all persons in the directory with the surname "Smith". 


For applications written in the Java programming language, a kind of 


data that is typically shared are Java objects themselves. For such 
applications, it makes sense to be able to use the directory as a 
repository for Java objects. The directory provides a centrally 


administered, and possibly replicated, service for use by Java 
applications distributed across the network. 
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For example, an application server might use the directory for 
"registering" objects representing the services that it manages, so 
that a client can later search the directory to locate those services 
as it needs. 


The motivation for this document is to define a common way for 
applications to store and retrieve Java objects from the directory. 
Using this common schema, any Java application that needs to read or 
store Java objects in the directory can do so in an interoperable 
way. 


2 Representation of Java Objects 


This document defines schema elements to represent three types of 
Java objects: a Java serialized object, a Java marshalled object, 
and a JNDI reference. A Java remote object is stored as either a Java 
marshalled object or a JNDI reference. 


2.1 Common Representations 


A Java object is stored in the LDAP directory by using the object 
class javaObject. This is the base class from which other Java object 
related classes derive: javaSerializedObject, javaMarshalledObject, 
and javaNamingReference. javaObject is an abstract object class, 
which means that a javaObject cannot exist by itself in the 
directory; only auxiliary or structural subclasses of it can exist in 
the directory. 


The object class javaContainer represents a directory entry dedicated 
to storing a Java object. It is a structural object class. In cases 
where a subclass of javaObject is mixed in with another structural 
object class, javaContainer is not required. 


The definitions for the object classes javaObject and javaContainer 
are presented in Section 4. 


The javaObject class has one mandatory attribute (javaClassName) and 
four optional attributes (javaClassNames, javaCodebase, javaDoc, 
description). javaClassName is a single valued attribute that is 
used to store the fully qualified name of the object’s Java class 
(for example, "Jjava.lang.String"). This may be the object’s most 
derived class’s name, but does not have to be; that of a superclass 
or interface in some cases might be most appropriate. This attribute 
is intended for storing the name of the object’s "distinguished" 
class, that is, the class or interface with which the object should 
be identified. 


Ryan, et al. Informational [Page 2] 


RFC 2713 Schema for Java Objects October 1999 


javaClassNames is a multivalued attribute that is used to store the 
fully qualified names of the object’s Java classes and interfaces 
(for example, "java.lang.Byte"). Like all multivalued attributes, the 
javaClassNames attribute’s values are unordered and so no one value 
is more "distinguished" than the others. This attribute is intended 
for storing an object’s class and interface names and those of its 
ancestor classes and interfaces, although the list of values does not 
have to be complete. If the javaClassNames attribute is present, it 
should include the value of javaClassName. 


For example, suppose an object is stored in the directory with a 
javaClassName attribute of "java.io.FilePermission", anda 
javaClassNames attribute of {"java.security.Permission", 
"Java.io.FilePermission", "java.security.Guard", 
"Java.io.Serializable"}. An application searching a directory for 
Java objects might use javaClassName to produce a summary of the 
names and types of Java objects in that directory. Another 
application might use the javaClassNames attribute to find, for 
example, all java.security.Permission objects. 


javaCodebase is a multivalued attribute that is used to store the 
location(s) of the object’s class definition. javaDoc is used to 
store a pointer (URL) to the Java documentation for the class. 
description is used to store a textual description of a Java object 
and is defined in [v3Schema]. The definitions of these attributes are 
presented in Section 3. 


2.2 Serialized Objects 


To "serialize" an object means to convert its state into a byte 
stream in such a way that the byte stream can be converted back into 
a copy of the object. A Java object is "Serializable" if its class 
or any of its superclasses implements either the java.io.Serializable 
interface or its subinterface java.io.Externalizable. 
"Deserialization" is the process of converting the serialized form of 
an object back into a copy of the object. When an object is 
serialized, the entire tree of objects rooted at the object is also 
serialized. When it is deserialized, the tree is reconstructed. For 
example, suppose a serializable Book object contains (a serializable 
field of) an array of Page objects. When a Book object is 
serialized, so is the array of Page objects. 


The Java platform specifies a default algorithm by which serializable 
objects are serialized. A Java class can also override this default 
serialization with its own algorithm. [Serial] describes object 
serialization in detail. 
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When an object is serialized, information that identifies its class 
is recorded in the serialized stream. However, the class’s definition 
("Class file") itself is not recorded. It is the responsibility of 
the system that is deserializing the object to determine the 
mechanism to use for locating and loading the associated class 
definitions. For example, the Java application might include in its 
classpath a JAR file containing the class definitions of the 
serialized object, or load the class definitions using information 
from the directory, as explained below. 


2.2.1 Representation in the Directory 


A serialized object is represented in the directory by the attributes 
javaClassName, javaClassNames, javaCodebase, and javaSerializedData, 
as defined in Section 3. The mandatory attribute, 
javaSerializedData, contains the serialized form of the object. 
Although the serialized form already contains the class name, the 
mandatory javaClassName attribute also records the class name of the 
serialized object so that applications can determined class 
information without having to first deserialize the object. The 
optional javaClassNames attribute is used to record additional class 
information about the serialized object. The optional javaCodebase 
attribute is used to record the locations of the class definitions 
needed to deserialize the serialized object. 


A directory entry that contains a serialized object is represented by 
the object class javaSerializedObject, which is a subclass of 
javaObject. javaSerializedObject is an auxiliary object class, which 
means that it needs to be mixed in with a structural object class. 
javaSerializedObject’s definition is given in Section 4. 


2.3 Marshalled Objects 


To "marshal" an object means to record its state and codebase(s) in 
such a way that when the marshalled object is "unmarshalled," a copy 
of the original object is obtained, possibly by automatically loading 
the class definitions of the object. You can marshal any object that 
is serializable or remote (that is, implements the java.rmi.Remote 
interface). Marshalling is like serialization, except marshalling 
also records codebases. Marshalling is different from serialization 
in that marshalling treats remote objects specially. If an object is 
a java.rmi.Remote object, marshalling records the remote object’s 
"stub" (see Section 2.5), instead of the remote object itself. Like 
serialization, when an object is marshalled, the entire tree of 
objects rooted at the object is marshalled. When it is unmarshalled, 
the tree is reconstructed. 
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A "marshalled" object is the represented by the 
java.rmi.MarshalledObject class. Here’s an example of how to create 
MarshalledObjects for serializable and remote objects: 


java.io.Serializable sobj = ...; 
java.rmi.MarshalledObject mobjl = 
new java.rmi.MarshalledObject (sobj) ; 


java.rmi.Remote robj = ...; 
java.rmi.MarshalledObject mobj2 = 
new java.rmi.MarshalledObject (robj); 


Then, to retrieve the original objects from the MarshalledObjects, do 
as follows: 


java.io.Serializable sobj = (java.io.Serializable) mobjl.get(); 
java.io.Remote rstub = (java.io.Remote) mob j2.get(); 


MarshalledObject is available only on the Java 2 Platform, Standard 
Edition, v1.2, and higher releases. 


2.3.1 Representation in the Directory 


A marshalled object is represented in the directory by the attributes 
javaClassName, javaClassNames, and javaSerializedData, as defined in 


Section 3. The mandatory attribute, javaSerializedData, contains the 
serialized form of the marshalled object (that is, the serialized 
form of a MarshalledObject instance). The mandatory javaClassName 


attribute records the distinguished class name of the object before 
it has been marshalled. The optional javaClassNames attribute is 
used to record additional class information about the object before 
it has been marshalled. 


A directory entry that contains a marshalled object is represented by 
the object class javaMarshalledObject, which is a subclass of 
javaObject. javaMarshalledObject is an auxiliary object class, which 
means that it needs to be mixed in with a structural object class. 
javaMarshalledObject’s definition is given in Section 4. 


As evident in this description, a javaMarshalledObject differs from a 


javaSerializedObject only in the interpretation of the javaClassName 
and javaClassNames attributes. 


Ryan, et al. Informational [Page 5] 


RFC 2713 Schema for Java Objects October 1999 


2.4 JNDI References 


Java Naming and Directory Interface(tm) (JNDI) is a directory access 
API specified in the Java programming language [JNDI]. It provides 
an object-oriented view of the directory, allowing Java objects to be 
added to and retrieved from the directory without requiring the 
client to manage data representation issues. 


JNDI defines the notion of a "reference" for use when an object 
cannot be stored in the directory directly, or when it is 
inappropriate or undesirable to do so. An object with an associated 
reference is stored in the directory indirectly, by storing its 
reference instead. 


2.4.1 Contents of a Reference 


A JNDI reference is a Java object of class javax.naming.Reference. 

It consists of class information about the object being referenced 
and an ordered list of addresses. An address is a Java object of 
class javax.naming.RefAddr. Each address contains information on how 
to construct the object. 


A common use for JNDI references is to represent connections to a 
network service such as a database, directory, or file system. Each 
address may then identify a "communications endpoint" for that 
service, containing information on how to contact the service. 
Multiple addresses may arise for various reasons, such as replication 
or the object offering interfaces over more than one communication 
mechanism. 


A reference also contains information to assist in the creation of an 
instance of the object to which the reference refers. It contains 
the Java class name of that object, and the class name and location 
of the object factory to be used to create the object. The 
procedures for creating an object given its reference and the reverse 
are described in [JNDI]. 


2.4.2 Representation in the Directory 


A JNDI reference is stored in the directory by using the attributes 
javaClassName, javaClassNames, javaCodebase, javaReferenceAddress, 
and javaFactory, defined in Section 3. These attributes store 
information corresponding to the contents of a reference described 
above. javaReferenceAddress is a multivalued optional attribute for 
storing reference addresses. javaFactory is the optional attribute 
for storing the object factory’s fully qualified class name. The 
mandatory javaClassName attribute is used to store the name of the 
distinguished class of the object. The optional javaClassNames 
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attribute is used to record additional class and interface names. 
The optional javaCodebase attribute is used to store the locations of 
the object factory’s and the object’s class definitions. 


A directory entry containing a JNDI reference is represented by the 
object class javaNamingReference, which is a subclass of javaObject. 
javaNamingReference is an auxiliary object class, which means that it 
needs to be mixed in with a structural object class. 
javaNamingReference’s definition is given in Section 4. 


2.5 Remote Objects 


The Java Remote Method Invocation (RMI) system [RMI] is a mechanism 
that enables an object on one Java virtual machine to invoke methods 
on an object in another Java virtual machine. Any object whose 
methods can be invoked in this way must implement the java.rmi.Remote 
interface. When such an object is invoked, its arguments are 
marshalled and sent from the local virtual machine to the remote one, 
where the arguments are unmarshalled and used. When the method 
terminates, the results are marshalled from the remote machine and 
sent to the caller’s virtual machine. 


To make a remote object accessible to other virtual machines, a 
program typically registers it with the RMI registry. The program 
supplies to the RMI registry the string name of the remote object and 
the remote object itself. When a program wants to access a remote 
object, it supplies the object’s string name to the RMI registry on 
the same machine as the remote object. The RMI registry returns to 
the caller a reference (called "sStub") to the remote object. When 
the program receives the stub for the remote object, it can invoke 


methods on the remote object (through the stub). A program can also 
obtain references to remote objects as a result of remote calls to 
other remote objects or from other naming services. For example, the 


program can look up a reference to a remote object from an LDAP 
server that supports the schema defined in this document. 


The string name accepted by the RMI registry has the syntax 
"rmi://hostname:port/remoteObjectName", where "hostname" and "port" 
identify the machine and port on which the RMI registry is running, 
respectively, and "remoteObjectName" is the string name of the remote 
object. "hostname", "port", and the prefix, "rmi:", are optional. If 
"hostname" is not specified, it defaults to the local host. If 
"port" is not specified, it defaults to 1099. If "“remoteObjectName" 
is not specified, then the object being named is the RMI registry 
itself. See [RMI] for details. 
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RMI can be supported using different protocols: the Java Remote 
Method Protocol (JRMP) and the Internet Inter-ORB Protocol (IIOP). 
The JRMP is a specialized protocol designed for RMI; the IIOP is the 
standard protocol for communication between CORBA objects [CORBA]. 
RMI over IIOP allows Java remote objects to communicate with CORBA 
objects which might be written in a non-Java programming language 
[RMI-IIOP]. 


2.5.1 Representation in the Directory 


Remote objects that use the IIOP are represented in the directory as 
CORBA object references [CORBA-LDAP]. Remote objects that use the 
JRMP are represented in the directory in one of two ways: as a 
marshalled object, or as a JNDI reference. 


A marshalled object records the codebases of the remote object’s stub 
and any serializable or remote objects that it references, and 
replaces remote objects with their stubs. To store a Remote object 
as a marshalled object (java.rmi.MarshalledObject), you first create 
a java.rmi.MarshalledObject instance for it. 


java.rmi.Remote robj = ...; 
java.rmi.MarshalledObject mobj = 
new java.rmi.MarshalledObject (robj); 


You can then store the MarshalledObject instance as a 
javaMarshalledObject. The javaClassName attribute should contain the 
fully qualified name of the distinguished class of the remote object. 
The javaClassNames attribute should contain the names of the classes 
and interfaces of the remote object. To read the remote object back 
from the directory, first deserialize the contents of the 
javaSerializedData to get a MarshalledObject (mob j), then retrieve it 
from the MarshalledObject as follows: 


java.rmi.Remote robj = (java.rmi.Remote)mobj.get (); 


This returns the remote stub, which you can then use to invoke remote 
methods. 


MarshalledObject is available only on the Java 2 Platform, Standard 
Edition, v1.2 and higher releases. Therefore, a remote object stored 
as a MarshalledObject can only be read by clients using the the Java 
2 Platform, Standard Edition, v1.2 or higher releases. 
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To store a remote object as a JNDI reference, you first create a 
javax.naming.Reference object instance for it using the remote 
object’s string name as it has been, or will be, recorded with the 
RMI registry, with the additional restriction that the "rmi:" prefix 
must be present. Here’s an example: 


javax.naming.Reference ref = new javax.naming.Reference ( 
obj.getClass().getName(), 
new javax.naming.StringRefAddr("URL", 
"rmi://rserver/AppRemoteObjectX") ); 


You then store the javax.naming.Reference instance as a 
javaNamingReference. The advantage of using a JNDI reference is that 
this can be done without a reference to the remote object. In fact, 
the remote object does not have to exist at the time that this 
recording in the directory is made. The remote object needs to exist 
and be bound with the RMI registry when the object is looked up from 
the directory. 


2.6 Serialized Objects Vs. Marshalled Objects Vs. References 


The object classes defined in this document store different aspects 
of the Java objects. 


A javaSerializedObject or a serializable object stored as a 
javaMarshalledObject represents the object itself, while a 
javaNamingReference or a remote object stored as a 
javaMarshalledObject represents a "pointer" to the object. 


When storing a serializable object in the directory, you have a 
choice of storing it as a javaSerializedObject ora 
javaMarshalledObject. The javaSerializedObject object class provides 
the basic way in which to store serializable objects. When you create 
an LDAP entry using the javaSerializableObject object class, you must 
explicitly set the javaCodebase attribute if you want readers of that 
entry to know where to load the class definitions of the object. When 
you create an LDAP entry using the javaMarshalledObject object class, 
you use the MarshalledObject class. The MarshalledObject class uses 
the RMI infrastructure available on the Java platform to automate how 
codebase information is gathered and recorded, thus freeing you from 
having to set the javaCodebase attribute. On the other hand, the 
javaCodebase attribute is human-readable and can be updated easily by 
using text-based tools without having to change other parts of the 
entry. This allows you, for instance, to move the class definitions 
to another location and then update the javaCodebase attribute to 
reflect the move without having to update the serialized object 
itself. 
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A javaNamingReference provides a way of recording address information 
about an object which itself is not directly stored in the directory. 
A remote object stored as a javaMarshalledObject also records address 
information (the object’s "stub") of an object which itself is not 
directory stored in the directory. In other words, you can think of 
these as compact representations of the information required to 
access the object. 


A javaNamingReference typically consists of a small number of human- 


readable strings. Standard text-based tools for directory 
administration may therefore be used to add, read, or modify 
reference entries -- if so desired -- quite easily. Serialized and 


marshalled objects are not intended to be read or manipulated 
directly by humans. 


3 Attribute Type Definitions 
The following attribute types are defined in this document: 


javaClassName 
javaClassNames 
javaCodebase 
javaSerializedData 
javaFactory 
javaReferenceAddress 
javaDoc 


3.1 javaClassName 


This attribute stores the fully qualified name of the Java object’s 
"distinguished" class or interface (for example, "Jjava.lang.String"). 
It is a single-valued attribute. This attribute’s syntax is ’ 
Directory String’ and its case is significant. 


( 16326. 464.1742 2.272 4.:126 
NAME ’ javaClassName’ 
DESC ‘’Fully qualified name of distinguished Java class or 
interface’ 
EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE 
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3.2 javaCodebase 


This attribute stores the Java class definition’s locations. It 
specifies the locations from which to load the class definition for 
the class specified by the javaClassName attribute. Each value of 
the attribute contains an ordered list of URLs, separated by spaces. 
For example, a value of "urll url2 url3" means that the three 
(possibly interdependent) URLs (urll, url2, and url3) form the 
codebase for loading in the Java class definition. 


If the javaCodebase attribute contains more than one value, each 
value is an independent codebase. That is, there is no relationship 
between the URLs in one value and those in another; each value can be 
viewed as an alternate source for loading the Java class definition. 
See [Java] for information regarding class loading. 


This attribute’s syntax is ’IA5 String’ and its case is significant. 


(2396.14 2542 .2.2754..07 
NAME ’ javaCodebase’ 
DESC ‘URL(s) specifying the location of class definition’ 
EQUALITY caseExactIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 


) 
3.3 javaClassNames 


This attribute stores the Java object’s fully qualified class or 
interface names (for example, "Jjava.lang.String"). It isa 
multivalued attribute. When more than one value is present, each is 
the name of a class or interface, or ancestor class or interface, of 


this object. 


This attribute’s syntax is ’Directory String’ and its case is 
significant. 


( 1.365 0.461342..232724. 1.13 
NAME ’ javaClassNames’ 
DESC "Fully qualified Java class or interface name’ 
EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
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3.4 javaSerializedData 


This attribute stores the serialized form of a Java object. The 
serialized form is described in [Serial]. 


This attribute’s syntax is ’Octet String’. 


(1.28.6 e 1 As 42. 2.27.54. 18. 
NAME ’ javaSerializedData 
DESC ‘Serialized form of a Java object’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 
SINGLE-VALUE 

) 


3.5 javaFactory 


This attribute stores the fully qualified class name of the object 
factory (for example, "com.wiz.jndi.WizObjectFactory") that can be 
used to create an instance of the object identified by the 
javaClassName attribute. 


This attribute’s syntax is ’Directory String’ and its case is 
significant. 


( 1.3.6.1.4.1.42.2.27.4.1.10 
NAME / javaFactory’ 


DESC ‘’Fully qualified Java class name of a JNDI object factory’ 


EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE 

) 


3.6 javaReferenceAddress 


This attribute represents the sequence of addresses of a JNDI 


reference. Each of its values represents one address, a Java object 


of type javax.naming.RefAddr. Its value is a concatenation of the 


address type and address contents, preceded by a sequence number (the 
order of addresses in a JNDI reference is significant). For example: 


#0#TypeA#ValA 
#1#TypeBiValB 
#2#TypeC##rOOABXNyABpa... 


In more detail, the value is encoded as follows: 
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The delimiter is the first character of the value. For readability 
the character ’#’ is recommended when it is not otherwise used 
anywhere in the value, but any character may be used subject to 
restrictions given below. 


The first delimiter is followed by the sequence number. The sequence 
number of an address is its position in the JNDI reference, with the 
first address being numbered 0. It is represented by its shortest 
string form, in decimal notation. 


The sequence number is followed by a delimiter, then by the address 
type, and then by another delimiter. If the address is of Java class 
javax.naming.StringRefAddr, then this delimiter is followed by the 
value of the address contents (which is a string). Otherwise, this 
delimiter is followed immediately by another delimiter, and then by 
the Base64 encoding of the serialized form of the entire address. 


The delimiter may be any character other than a digit or a character 


contained in the address type. In addition, if the address contents 
is a string, the delimiter may not be the first character of that 
string. 


This attribute’s syntax is ’Directory String’ and its case is 
significant. It can contain multiple values. 


CAs 3 bee 4 TAD 232704. 1 Ed 
NAME ’ jJavaReferenceAddress’ 
DESC ‘Addresses associated with a JNDI Reference’ 
EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 


) 
3.7 javaDoc 


This attribute stores a pointer to the Java documentation for the 
class. It’s value is a URL. For example, the following URL points to 
the specification of the java.lang.String class: 
http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String. html 


This attribute’s syntax is ’IA5 String’ and its case is significant. 


(rls 316.4 E Be? 27 24 N 
NAME ’ JavaDoc’ 
DESC ‘’The Java documentation for the class’ 
EQUALITY caseExactIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
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4 Object Class Definitions 
The following object classes are defined in this document: 


javaContainer 
javaObject 
javaSerializedObject 
javaMarshalledObject 
javaNamingReference 


4.1 javaContainer 


This structural object class represents a container for a Java 
object. 


C Bes S T E 1 A? 2227 A 27 
NAME ’ javaContainer’ 
DESC ‘Container for a Java object’ 
SUP top 
STRUCTURAL 
MUST ( cn ) 
) 


4.2 javaObject 


This abstract object class represents a Java object. A javaObject 
cannot exist in the directory; only auxiliary or structural 
subclasses of it can exist in the directory. 


(186s As E A E 

NAME ’ javaObject”’ 

DESC ‘Java object representation’ 

SUP top 

ABSTRACT 

MUST ( javaClassName ) 

MAY ( javaClassNames $ 
javaCodebase $ 
javaDoc $ 
description ) 
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4.3 javaSerializedObject 


This auxiliary object class represents a Java serialized object. It 


must be mixed in with a structural object class. 


(rE Biv6sl 4s 1 42 [227 A259 
NAME ’ javaSerializedObject’ 
DESC ‘Java serialized object’ 
SUP javaObject 
AUXILIARY 
MUST ( javaSerializedData ) 


) 


4.4 javaMarshalledObject 


This auxiliary object class represents a Java marshalled object. It 


must be mixed in with a structural object class. 


C2336. 4s D422. 27 E: 
NAME ’ javaMarshalledObject’ 
DESC ‘Java marshalled object’ 
SUP javaObject 
AUXILIARY 
MUST ( javaSerializedData ) 


) 


4.5 javaNamingReference 


This auxiliary object class represents a JNDI reference. It must be 


mixed in with a structural object class. 


(273%6. 1420.42 2.27 T 
NAME ’ jJavaNamingReference’ 
DESC ’JNDI reference’ 

SUP javaObject 


AUXILIARY 
MAY ( javaReferenceAddress $ 
javaFactory ) 
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5. Security Considerations 


Serializing an object and storing it into the directory enables (a 
copy of) the object to be examined and used outside the environment 
in which it was originally created. The directory entry containing 
the serialized object could be read and modified within the 
constraints imposed by the access control mechanisms of the 
directory. If an object contains sensitive information or 
information that could be misused outside of the context in which it 
was created, the object should not be stored in the directory. For 
more details on security issues relating to serialization in general, 
see [Serial]. 
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Appendix - LDAP Schema 
—- Attribute types -- 


E EEE 6a ANd 42 2.27 742136 
NAME ’ javaClassName’ 
DESC ’Fully qualified name of distinguished Java class or interface’ 
EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE 


(eS 6a AL A222 E Ll 
NAME ’ javaCodebase’ 
DESC ‘URL(s) specifying the location of class definition’ 
EQUALITY caseExactIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 


Ch eS OA A 22 2 Al 8 
NAME ’ javaSerializedData’ 
DESC ‘Serialized form of a Java object’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 
SINGLE-VALUE 


(1 63.-6:5 141.422.2707 04.1 210 
NAME / javaFactory’ 
DESC "Fully qualified Java class name of a JNDI object factory’ 
EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE 


( 1.3.6.1.4.1.42.2.27.4.1.11 
NAME ’ jJavaReferenceAddress’ 
DESC ‘Addresses associated with a JNDI Reference’ 
EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 


(abs 3 6414142 227A 12 
NAME ’ JavaDoc’ 
DESC ‘The Java documentation for the class’ 
EQUALITY caseExactIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
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(1.23641 461642 225.27 641.13 
NAME ’ javaClassNames’ 
DESC ‘’Fully qualified Java class or interface name’ 
EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 


) 
-- from RFC-2256 -- 


C2. 2054213 
NAME ‘description’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselIgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 


) 


-—- Object classes -- 


(363d 4, AD 2 2774s 2k 
NAME ’ jJavaContainer’ 
DESC ’Container for a Java object’ 
SUP top 
STRUCTURAL 
MUST ( cn ) 
) 


(D365 4e1 e422 E 
NAME ’ JavaObject’ 
DESC ‘Java object representation’ 
SUP top 
ABSTRACT 
MUST ( javaClassName ) 
MAY ( javaClassNames $ javaCodebase $ javaDoc $ description ) 


) 


C638 604i dl AD S227 S425 
NAME ’ javaSerializedObject’ 
DESC ‘Java serialized object’ 
SUP javaObject 
AUXILIARY 
MUST ( javaSerializedData ) 
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( 


15364 A222 sais 

NAME ’ jJavaNamingReference’ 

DESC ’JNDI reference’ 

SUP javaObject 

AUXILIARY 

MAY ( javaReferenceAddress $ javaFactory ) 


Ag SO AR AD e227. Ae 238 
NAME ’ javaMarshalledObject’ 
DESC ‘Java marshalled object’ 
SUP javaObject 

AUXILIARY 

MUST ( javaSerializedData ) 


Matching rule from ISO X.520 -- 
2.6 9413.55 


NAME ’caseExactMatch’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
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